1987-Club80-21 S.53-54
Was habt Ihr gegen CP/M ?Jedesmal, wenn sich einer der TRS-80/GENIE-Päpste zu CP/M äußert, sträuben sich bei mir die Nackenhaare. Da kommen dann Äußerungen zu Papier, die dem unvoreingenommenen Info-Leser gleich die Vorstellung aufzwingen, daß man von CP/M lieber die Finger läßt, wenn ein Herr H. aus E. oder ein Herr S. aus L. damit nicht arbeiten wollen oder vorgeben, damit Schwierigkeiten zu haben. Die gleichen Herren bedienen sich aber gerne der CP/M-Programme, die unter NEWSOS oder GDOS nicht verfügbar sind. Und gerade die Vielzahl guter Programme, die unter CP/M laufen, ist eines der Hauptargumente für dieses Betriebssystem. Ein weitere Pluspunkt für CP/M ist seine Hardware-Unabhängigkeit. Voraussetzung auf der Hardwareseite ist lediglich, daß als CPU ein 8080, Z80, HD64180 oder Z280 vorliegt und daß ein Umschalten zwischen ROM und RAM (ab 0000H) möglich ist. Nach dem Abschalten des Boot-ROMs muß ein zusammenhängender RAM-Speicher von 0000H an vorliegen. Wie Peripherie angeschlossen ist, spielt keine Rolle. Diese Hardware-Komponenten werden entsprechend im BDOS berücksichtigt. Das BDOS ist der Teil des Betriebssystems, der elementare I/O-Operationen mit der Hardware erledigt (z.B. Zeichen von der Tastatur holen, Zeichen auf dem Bildschirm ausgeben, Sektor von Diskette lesen oder auf Diskette schreiben u.s.w.). Da durch Anpassung im BIOS CP/M auf jeder Hardware-Kombination zum Laufen zu kriegen ist, ist es völlig egal, ob der Bildschirm memory mapped CPU-Adreßraum verschlingt oder als seriell angeschlossenes Terminal bereitsteht. Diese Vielfalt an möglichen Computerarchitekturen ließ in der Blütezeit der 8Bit-Rechner (und auch heute noch) hervorragende Maschinen entstehen, die sich in der Hardware zwar alle unterschieden, auf denen aber alle CP/M-Programme liefen. Die neuere Enrwicklung durch Einstieg eines führenden Großrechner-Herstellers in den Microcomputer-Markt mit einem Möchtegern-16Bit-Prozessor und einem dem CP/M ähnlichen Betriebssystem führte aber ungewollt in eine Sackgasse. Das DOS dieser Geräte sieht zwar auch die Abwicklung der I/O-Operationen über Betriebssystem-Aufrufe vor, was aber wegen der erbärmlichen Geschwindigkeit der Bildschirmausgabe nicht eingehalten worden ist. Die meisten Programme bedienen die Peripherie direkt (ähnlich wie wir das von allen besseren Programmen unter NEWDOS/GDOS kennen). Dieses Verhalten der Software-Anbieter führte dazu, daß nur der Hardware- Hersteller sein Gerät verkaufen konnte, der es 100% kompatibel zum Vorbild baute. Wenn diese Voraussetzung nicht erfüllt war, liefen viele Programme nicht einwandfrei, derentwegen der Anwender sich das Gerät gekauft hatte. Mit solchen Geräten ist nicht viel zu verdienen. Der Begriff "Industrie- Standard" ist nur eine positive Bezeichnung dieser Misere. Dahinter verbirgt sich ein in der Hardware völlig festgefahrenes System, das mit dem TRS80 in dieser Hinsicht durchaus vergleichbar ist. Aber zurück zum TRS80 und seinen Nachfolgern. Die fest vorgegebene und recht verbaute Hardware und die direkt darauf zugreifenden Programme ließen wenig Spielraum für Verbesserungen, ohne daß das Gerät die TRS80- Kompatibilität einbüßt. Um CP/M fahren zu können, war es nötig, daß Floppy, Drucker, Tastatur und Bildwiederholspeicher nicht mitten im Adreßraum der CPU liegen. Für NEWDOS/80 und GDOS war das aber zwingend. Es wurden Banker entwickelt, die zwischen ROM und memory mapped I/O und RAM umschalten oder nur zwischen ROM und RAM umschalten und memory mapped I/0 an das obere Speicherende verschieben. Mit teilweise riesigem Aufwand wurde die gleichzeitige TRS8O-Kompatibilität und CP/M-Fähigkeit erreicht. In einem Testbericht der CHIP zum GIIIs liest sich das so: "Mußte es denn ausgerechnet eine 8Bit-Maschine sein, in die soviel Arbeit und Ideenreichtum gesteckt wurde ?" Dabei kann die Architektur eines CP/M-Rechners sehr einfach ausfallen, wenn man auf die TRS-80-Kompatibilität verzichtet (siehe mc-CP/M-Computer). Es ist also nicht verwunderlich, daß bei dem dafür nötigen Aufwand und den damit verbundenen Einschränkungen heute niemand mehr TRS-80-kompatible Computer anbietet. Aber nicht nur die geringen Anforderungen an die Hardware und die damit verbundene Gerätevielfalt und das riesige Software-Angebot sprechen für CP/M. Auch das Programmieren in Maschinensprache ist unter CP/M sehr viel einfacher. Alle Betriebssystem-Aufrufe und Hardware-Zugriffe erfolgen über CALL 0005H, wobei im Register C immer die gewünschte Funktion ausgegeben wird und in anderen Registern je nach Funktion die Parameter übergeben/übernommen werden. Der Programmierer braucht sich über die Hardware-Architektur überhaupt keibe Gedanken zu machen. Daß nun ausgerechnet unsere Software-Päpste um CP/M einen großen Bogen machen, liegt wahrscheinlich daran, daß sie die enorme Arbeit, die investiert werden muß, um mit NEWDOS/GDOS umgehen zu können, nicht umsonst geleistet haben wollen, und auch nicht bei CP/M noch einmal von vorne anfangen wollen. Es kostet tatsächlich einige Überwindung, anstelle von ZEUS nun ein Maschinenprogramm mit Wordstar zu schreiben und mit einem der zahlreichen Assembler zu übersetzen. Man muß gleich mehrere Handbücher wälzen. Etwas fadenscheinig kommen mir die Argumente wie miese Leistungsfähigkeit und mangelnder Bedienugskomfort vor. Zugegeben, es ist schon etwas lästig, wenn man sich immer erst erinnern muß, in welchen Drive nun die Diskette steckt, auf der die gewünschte Datei vorliegt. NRWDOS sucht mir das selbst heraus. Andererseits ärgert mich bei NEWDOS das dort übliche DIR-Chaos. Ein neu auf die Diskette geschriebener File verschwindet irgendwo mittenzwischen den schon auf der Scheibe vorhandenen Files. Dagegen wird von CP/M das Directory so ausgegeben, wie die Einträge nacheinander erfolgt sind. Und dann gibt es da noch diese herrlichen Wildcards, mit denen eine selektive Anzeige des Directory möglich ist. Die vorgeworfene geringe Leistungsfähigkeit von CP/M ist eher als Vorteil zu sehen. Dadurch, daß CP/M nur auf seine Betriebssystem-Funktionen beschränkt ist, nimmt es wenig Speicherplatz weg und braucht auch nicht mit Overlay Technik zu arbeiten. Alle über die Betriebssystem-Funktionen hinausgehenden Leistungen müssen entsprechende Programme liefern, und dafür gibt es sehr gute Utilities. Es ist mir völlig gleichgültig, ob ein Disketten-Kopieren mit einem Betriebssystem-Befehl oder mit einem Programm durchgeführt wird, ausschlaggebend ist der Komfort bei der ganzen Aktion. Und schließlich habe ich als CP/M-User Anschluß an all die vielen Z80-Rechner, die in den letzten 10 Jahren auf den Markt gebracht wurden. Was bei mir läuft, ist auch dort verwendbar und umgekehrt. |